## Introduction

In my last posts you’ve learned about:
- [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/)
- [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/)
- [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/) and
- [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/)

Today I would like to describe the last event in the Scrum Events series - Sprint Retrospective.

## Definition and length

Definition in the Scrum Guide:

> The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

As you can see, this event similarly to [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) is focused on the inspection. The main difference between [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and Retrospective is a subject. [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) is about review and inspection of the **increment**, while Sprint Retrospective is dedicated to inspection of the **Scrum Team itself**.

Regarding length and occurence of the event, based on the Scrum Guide:

> The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

**Who should attend the event?**

**Scrum Team** - Development Team, Product Owner and Scrum Master. Scrum Master needs to make sure that event is organized and everyone understands the purpose.
Before we jump into the purpose, let’s find the Sprint Retrospective in the running analogy that I used in the whole series. I believe that Sprint Retrospective is like the moment when you finish sprinting and you start analyzing your behaviour, speed and everything else that could impact your running. Before you will start preparing for the next run, you want to know what was working for you and what should be adjusted to perform better.

![Analysis](img/analysis.jpg)

## Purpose

Following the Scrum Guide:

> The purpose of the Sprint Retrospective is to:
> - Inspect how the last Sprint went with regards to people, relationships, process, and tools;
> - Identify and order the major items that went well and potential improvements; and,
> - Create a plan for implementing improvements to the way the Scrum Team does its work.

Sprint Retrospective gives the opportunity for the Scrum Team to observe their actions and learn from experience. It’s time when they can analyze:
* What went well during the Sprint? - What they didn’t like and should be improved? - What solutions can be implemented to make their work more effective?

Scrum Master should encourage the Team to improve processes and practices to make their work more fun and effective. The continuous improvement is the important part of the Scrum. Making changes and adapting to the current situation is necessary in order to increase product quality. In my opinion it is also crucial for the team and personal development of each team member.

What is the main purpose of the Sprint Retrospective in my opinion? I believe it is an honest discussion about the Sprint and ideas for improvement. I would like to emphasize how important transparency and honesty are during that meeting. It is not possible to make real improvement without honest opinions of team members.

## Celebration
Let me describe the main 3 parts of the Sprint Retrospective.

First of all this event is a great opportunity to celebrate successes and remind all positive aspects of the Sprint. It’s perfect time to appreciate what other team members did and how they did it. This approach helps to build a motivated and collaborative team.
People keep forgetting about positive aspects of their lives and have a tendency to focus on the negative situations. Without knowledge about successes and good solutions, the Scrum Team cannot keep growing. They need to know what is working for them and what they would like to continue doing.

![Celebration](img/celebration.jpg)

## 2) Did not go well

After discussion about positive aspects of the Sprint is time to face with everything that didn't go well. The important part is to create the safety space for team members to express what they think. The only way to achieve it, is creation of a blame-free and full of trust environment.

Let’s remember that during Sprint Retrospective, team members don’t focus only on their work. It’s time for discussion also about relationships or conflicts if they appeared. I would say that is the most challenging bit that they can struggle with. Talking about processes and tools is much easier than telling someone that we didn’t like their behavior or attitude. During this kind of discussion the Scrum Team needs to remember about respect to everyone and openness to feedback.

## Improvements & ideas

Once the major items that didn’t go well are identified, the Scrum Team should try to find the best improvements that can be implemented. That’s a time for brainstorming and sharing all ideas with the team. Team members don’t need to focus on the solutions for the existing issues, but they can suggest any ideas that will make their work and relationships better.
If it’s possible, they can adjust Definition of Done considering the organizational standards and processes.

When all improvements are listed, the Scrum Team needs to decide what will be implemented in the next Sprint and they should include them in the Sprint Backlog.

![Ideas](img/ideas.jpg)

## Summary

There are a lot of examples how Sprint Retrospective can be facilitated. I didn’t include them here, because I wanted to start from describing the main idea and purpose of the meeting first. I will definitely write a post fully focused on the retrospective ideas.

The most important information about Sprint Retrospective:
* It’s an event focused on inspection and adaptation of the Scrum Team itself.

* Time: 3 hours for the one month Sprint.

* When is it happening? After [Sprint Review](https://letsscrumit.com/scrum-events-4-sprint-review/) and before the next [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/).

* The purpose: inspect what went well, what didn’t go well and what should be improved in regards to people, relationships, processes and tools.

* It’s an opportunity to celebrate successes and appreciate others' work.

* Discussion about items that didn’t go well should be done without blaming others, but with openness, trust and respect to everyone.

* During Sprint Retrospective, the Scrum Team should try to find the best solutions to solve their issues and improvements that will make their work and relationships better.

Let’s talk about my favourite and last Scrum Event - Sprint Retrospective. I described when it is happening and what is the purpose of that event.

Scrum Events #5 Sprint Retrospective

## Introduction

Few weeks ago I started a series of posts dedicated to Scrum Events.I’ve already described the [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/), [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) and [Daily Scrum](https://letsscrumit.com/scrum-events-3-daily-scrum/).  In this post I would like to tell you more about Sprint Review. 

![Sprint-Review](img/sprint_review.png)

## Definition and length

To understand the Sprint Review, we need to start from the definition in the Scrum Guide:

>A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. 

Inspection and adaptation are two of the three pillars of **Empiricism** (third one is transparency) which is the foundation of the Scrum. In empirical process control, knowledge comes from experience and that’s exactly what is happening during the Sprint Review. 
Scrum Team together with all stakeholders inspect the increment and decide what should be done next. 

Maximum duration of the Sprint Review is **four hours** for one-month Sprint. Scrum Master needs to make sure that event takes place and all attendees are aware of the purpose and keep time limits. 

If we continue the analogy to running, Sprint Review is like the finishing line. It is the moment when we verify how fast we were running, celebrate success and then based on this we can plan our running techniques for the next race. 

![Finising-Line](img/finishline.jpg)

## Collaboration

One of the most important parts of Agile mindset is collaboration - with clients, development team and business. In my post [The Relationship between Scrum and Agile](https://letsscrumit.com/relationship-between-scrum-and-agile/) you can read more about Agile and why it is strictly related to Scrum. 

Sprint Review is focused on the collaboration of all stakeholders and Scrum Team.  In the traditional product development the final result/product is presented to stakeholders at the end of the project. If it is a complex product it can take months or even years. 

In Scrum, Ken Schwaber and Jeff Sutherland proposed different approach: 
* Frequent delivery of the increment (not fully completed product).  

* Collecting the stakeholders’ feedback during development of the product. 

* Collaboration with all of them to optimize the value.

Collaboration with the customer is necessary to satisfy them and fulfill their needs. Moreover it saves a lot of Development Team’s time, because they know the direction of the development and they adjust their work if needed. I believe that this approach is much more effective and valuable than traditional development of the products.

![Collaboration](img/collaboration.jpg)

## Done & not Done work explained

Sprint Review is the time for the Product Owner to explain what has been "Done" during the Sprint and what has not been "Done".  The Development Team should demonstrate "Done" work and answer all stakeholders’ questions about the increment. That’s the moment for stakeholders to play around with the product and check if all their needs and priorities are fulfilled. 

It is important to mention that the Development Team should make sure that they present only "Done" work using the definition that they agreed for. 

The Sprint Review event is also time for discussion about positive aspects of the Sprint (successes), issues that appeared and how they were solved. It can be a great opportunity to discuss communication between stakeholders and the Scrum Team and find the best solutions.

![Done](img/Done.jpg)

## Product Backlog - now & the future

Product Owner presents the current status of the Product Backlog and gives the estimation of delivery based on the team velocity. It’s important to mention that it is just the prediction, not fixed dates. Specific plans for each Sprint are created by the Scrum Team during the [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) session.

All stakeholders and the Scrum Team should collaborate about priorities for the upcoming Sprint. They can be related to change in the marketplace or business strategy. It is important to analyze and decide what will deliver the maximum value to the business.

The outcome of the Sprint Review should be the revised Product Backlog that will include prioritized work items for the next Sprint. It will be used by the Scrum Team in the next [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/) meeting. 
![Direction](img/direction.jpg)

## Summary

The most important information about Sprint Review meeting: 
* The maximum duration of the meeting is 4 hours for one month Sprint. 

* Participants: Scrum Team and stakeholders invited by Product Owner. 

* Collaboration is a crucial part of the meeting. It is time for collection of feedback and understanding stakeholders’ needs. 

* The Product Owner should explain what was "Done" and not "Done" during the Sprint. - The Development Team demonstrates "Done" Increment. 

* It is also time for discussion about positive and negative aspects of the Sprint in order to create the best solution for the future.

* During Sprint Review Product Backlog should be presented by the Product Owner with the estimated plan for the future.  

* All participants should collaborate to decide about work priorities and the direction for the next Sprint.

Sprint Review is a great tool for Scrum Team that helps to verify if stakeholders are happy about the increment and what is the most important work that needs to be included in the next iteration. This knowledge helps to plan the work and deliver business value. 

Are you at the end of the Sprint wondering what should happen next? It's time for Sprint Review meeting! Here you can find more details about it.

Scrum Events #4 Sprint Review

## Introduction

In my last 2 posts from Scrum Events series I described what is [Sprint](https://letsscrumit.com/scrum-events-1-the-sprint/) and [Sprint Planning](https://letsscrumit.com/scrum-events-2-sprint-planning/). Today I would like to focus on the event that can be easily forgotten or incorrectly transformed into a status meeting.
 
It’s time to talk about **Daily Scrum**.

![Daily-Scrum](img/Daily_scrum_1.png)

## Definition and length

Let’s start from definition of the Daily Scrum written in the **Scrum Guide** : 

> The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.

First of all, the same as all events in Scrum, Daily Scrum is time-boxed. The maximum duration of the event is 15 minutes. The meeting should be organized daily at the same time and place to reduce complexity and to help the Development Team get into the habit of this daily activity.

## Inspection, not a status meeting

Continuing the analogy to running, Daily Scrum is like a line that is showing you the distance to the final destination. It is a great tool that helps you to inspect how far away you are. Sometimes it can motivate you to run faster or change your previous running technique. 

Daily Scrum is the event dedicated for inspection of how far the Development Team is from achieving the Sprint Goal. It is verification if they are on the right track or they need to somehow adjust the work. 

I would like to highlight that this event is for the Development Team to inspect their work, not for anyone else. They work together to accomplish what they planned as a self-organized team.  Scrum Master should make sure that event is happening and make sure that the event is not disrupted by anyone else.  It’s important to remember that Daily Scrum is not the status meeting for Product Owner or anyone else. 

![Inspection](img/inspect.jpg)

## Mustical 3 questions?

In the Scrum Guide there is an example of 3 questions that Development Team can answer during the Daily Scrum event: 

> - What did I do yesterday that helped the Development Team meet the Sprint Goal?
> - What will I do today to help the Development Team meet the Sprint Goal?
> - Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Let’s remember that it is just the guidance. Some teams can prefer discussion - based meetings. The most important for them is to inspect progress towards the Sprint Goal and plan work for the next 24 hours. How will they do it? It’s up to them and that’s why it’s mentioned in the Scrum Guide that 3 questions are just “an example”. 

## Sprint Goal - again?
I’ve already mentioned and described why **Sprint Goal** is an important part of the Scrum in my post [Sprint Goal in Scrum - why do we need it?](https://letsscrumit.com/sprint-goal-why-do-we-need-it/)

The main purpose of the Daily Scrum event is to discuss progress towards the Sprint Goal. I will probably sound like a broken record, but I need to emphasise Sprint Goal’s value in the event.

It is important to mention it, because the Development Team has a tendency to forget about the Sprint Goal and discuss **all work** done a day before and planned for the next 24 hours, even if it wasn’t related to the goal. It can obviously impact the length of the meeting and result in forgetting **why** the team did the work that they did.  I believe that reminding yourself **why** you are doing your work and what is your goal helps you to stay motivated and focused. 

The simple but really useful for Development Team can be a visual representation of the Sprint Goal on their Scrum board or anything else that they are using for daily inspection. It will be a reminder for them to always refer to the progress towards the Sprint Goal.

![Sprint-Gaol](img/goal.jpg)

## Too long Daily Scrum

One of the most common issues related to the Daily Scrum is extending the 15 minutes length.  First of all, Scrum Master should teach the Development Team to keep the meeting within the time frame. It can be challenging, especially with a talkative team. :D 

There are simple tricks that can help in keeping the meeting within 15 minutes time-box: 
* **Focus on the Sprint Goal** - talk only about the work related to the Sprint Goal, not everything what you did or plan to do

* **No technical details** - do not explain technical details of your work or impediments

* **Detailed discussions saved for later** - if there is a need to discuss some issues or plans in detail, it should be done after Daily Scrum. It will definitely save time for people who will not be involved in the discussed subject.

* **Set up time per person** - depending on the size, the Development Team can set up the maximum time for talking per each person. They can even use a timer to count it.

* **Stand up during the meeting** - it is easier to keep the meeting short if people do not sit down. 

## Value of the Daily Scrum

As a Scrum Master, when I hear the question: "Can we skip the Daily Scrum? We have nothing to talk about.", I know that it is the time to step in and something is wrong.  It is important to teach the Development Team, what is the value of Daily Scrum and how it can be beneficial for them. 

* **Inspection and Adaptation** - it is time for the team to inspect their work and adapt if there is a need for change. They can track if they are progressing towards the Sprint Goal or not. As soon as the team forgets about the Sprint Goal, they lose track of why they are doing their work. That’s why they don’t know what to talk about during the meeting.

* **Communication** - quick discussion about progress of a team improves communication and helps the Development Team to be on the same page in regards to what needs to be done and what issues they are struggling with.  Eliminate other meetings - Team knows what is the plan for the next 24 hours and there is no need for other long, time-consuming meetings.

* **Quick fix** - Daily Scrum promotes removing impediments as soon as possible. Early recognition of issues can help in finding the quick solution. 

* **Team support** - Daily Scrum is a reminder for the Development Team that all individual’s actions impact the team, but the team can be supportive and helpful in resolving any issues. The most important is to collaboratively strive to achieve the Sprint Goal. 

![Values](img/team.jpg)

## Summary
The most important information about Daily Scrum to remember are:
* It is a 15 minutes time-boxed event that happens daily.

* It is an internal meeting for the Development Team.

* Daily Scrum is the inspection event, not a status meeting.

* During the meeting, the team should inspect the progress towards the Sprint Goal and adapt to the situation (change their actions) if needed.
Sprint Goal helps the team to realize why they are doing their work.

* The Development Team should keep the 15 minutes time frame. 

* The Scrum Master role is to make sure that the team has a meeting and they do not extend 15 minutes.

* Daily Scrum benefits are: better communication, no need for other meetings, quick fix of issues and support of the team.

I hope my explanation of the Daily Scrum helped you to understand the purpose and value of that event. Feel free to share your thoughts about it on LinkedIn or Twitter!

Are you wondering what is the purpose of the Daily Scrum? Jump in and learn why it is not a status meeting from my third post in the Scrum Events series.

Scrum Events #3 Daily Scrum

## Introduction

\*This post has been updated based on the [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html)

In my [last post](/blog/scrum-events-1-the-sprint/) I’ve started the Scrum Events series and described the first event in Scrum - **Sprint**. If you haven’t read it yet, I recommend you do it before reading this article. 

Today I would like to continue the series by describing the event which  **initiates** the [Sprint](/blog/scrum-events-1-the-sprint/) - **Sprint Planning**.

Please take into consideration that some parts of the **Sprint Planning** that I described are not explicitly explained in the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) and I used examples of the common practices or my personal opinion.

## Sprint Planning - definition and length

Each [Sprint](/blog/scrum-events-1-the-sprint/) starts from the event called - **Sprint Planning**. During this meeting, Scrum Team: [Developers](/blog/scrum-roles-1-development-team), [Product Owner](/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master) collaboratively creates a plan of the work for the upcoming iteration. 

The meeting is time-boxed (the same as all events in [Scrum](/blog/first-steps-to-learn-scrum)) to a maximum of 8 hours for a monthly [Sprint](/blog/scrum-events-1-the-sprint/). Of course in case of shorter [Sprints](/blog/scrum-events-1-the-sprint/), the time is adjusted.

To help you understand the **Sprint Planning**, I would like to continue my analogy to sport from the previous post. This event is like the moment of the **start in sprinting** (short distance running). If you start running too fast, before the signal to begin, the whole race must be restarted due to false start. On the other hand, if you miss the start, it can jeopardize your whole run and final result.

It is exactly the same in [Scrum](/blog/first-steps-to-learn-scrum). The Scrum Team needs to **work together** to start the [Sprint](/blog/scrum-events-1-the-sprint/). If someone will start before others, **transparency** will be lost and it will have a huge impact on the [Sprint](/blog/scrum-events-1-the-sprint/). Additionally, any delays in start, misunderstandings and not clear requirements can also delay the [Sprint](/blog/scrum-events-1-the-sprint/) and negatively affect the final outcome.

## Why?

The first part of the Sprint Planning should be focused on the explanation of **"Why?"** by the [Product Owner](/blog/scrum-roles-2-product-owner). In the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) it is explained shortly:

> The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

I would add to this description an explanation of the high level idea for the product:

* How will the upcoming Sprint **impact** the development of the product?
* What were the **changes** from the previous Sprint that impacted the top of the Product Backlog? What needs to be taken into consideration during the Sprint Planning?

From my experience, it is much easier to start working on something if you know the **background** and understand the **purpose** of your actions. Of course details for each part of work should be explained in the work item’s Acceptance Criteria, but it is important for the Scrum Team to understand the whole picture.

It can be helpful if the  [Product Owner](/pl/blog/scrum-roles-2-product-owner)  starts from the **Sprints Roadmap**, and explain the Product Goal. I like the roadmap analogy, because I imagine that as a Scrum Team we are starting the trip together. It is much easier to achieve the first goal if we know roughly about the **next destinations.** FYI - it’s different from the roadmap used in project management. This is just high level vision based on the velocity of the team and it is adjusted whenever changes occur. 

![Sprint-Roadmap](img/roadmap.webp "Roadmap")

The next step of the **Sprint Planning** is setting up the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) by the Scrum Team. It is the objective that they want to achieve during the upcoming iteration. [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) should be valuable and clear to everyone. It helps the team focus and understand why they are doing their work. 

## What?

After “Why” of the [Sprint](/blog/scrum-events-1-the-sprint/) it is time for a discussion about  **what** will be done during the [Sprint](/blog/scrum-events-1-the-sprint/). 
[Product Owner](/blog/scrum-roles-2-product-owner) &  [Developers](/blog/scrum-roles-1-development-team) collaborate on what  [Product Backlog](/blog/scrum-artifacts-1-product-backlog) items will be included in the current [Sprint](/blog/scrum-events-1-the-sprint/). The list of items selected for the Sprint is called **Sprint Backlog**.

If it is not the first [Sprint](/blog/scrum-events-1-the-sprint/) of this team, there are some inputs to the Sprint Planning session like:

* **Projected capacity** - total number of hours that the team will be available during the [Sprint](/blog/scrum-events-1-the-sprint/).
* **Velocity** - average amount of Product Backlog turned into [Increment](/blog/scrum-artifacts-3-the-increment) during previous [Sprints](/blog/scrum-events-1-the-sprint/).
* **Their Definition of Done** - how they will recognize that the work item is “Done”.

It is up to the [Developers](/blog/scrum-roles-1-development-team) to select how many work items can be done within the [Sprints](/blog/scrum-events-1-the-sprint/). It is one the first moments in  [Scrum](/blog/first-steps-to-learn-scrum) when [Product Owner](/blog/scrum-roles-2-product-owner) needs to trust the team members that they will select the right amount of work based on their expertise and previous experience. Nobody knows better how much work  [Developers](/blog/scrum-roles-1-development-team)  can do during the [Sprint](/blog/scrum-events-1-the-sprint/) than themselves.

## How?

Once the [Developers](/blog/scrum-roles-1-development-team) knows why they need to do the work during the Sprint and they decide what will be done, it is time to decide **how** it will happen.

Let’s check what we can read in the  [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) about it:

> For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

It is not mentioned there, because it seems to be obvious, but [Developers](/blog/scrum-roles-1-development-team) need to decide **how** they will be **checking** daily if they are going in the right direction with their work. How do they plan to **track the work, communicate** with each other? They will be meeting on a Daily Scrum, but what more?

There are some technical aspects that I believe need to be discussed:

* How will they track the **progress** of our work? Do they want to use the **Kanban** Board? If yes, will they use columns "To do", "In progress" and "Done" or others that will be more accurate for their work?
* Would they like to use **tools** like Sprint Burndown or Burnup charts to see if they are still on the right track in order to achieve the  [Sprint Goal](/blog/sprint-goal-why-do-we-need-it)?
* How about **bugs**? Do they consider having items called "bugs"? If yes, how do they plan to manage them?
* What about **communication** within the team? Do they plan to communicate only face to face or using emails, Microsoft Teams, Zoom or any other tool?

It is possible that there will be more technical aspects that the Scrum Team should discuss. I think that it is important to talk about them and have a common understanding of communication and the whole collaboration process. It doesn’t need to be a long discussion. It can be just a quick agreement to make sure everyone is on the same page.

![How?](img/how.webp "How")

Once it’s all sorted out, [Developers](/blog/scrum-roles-1-development-team) can decide about the **size** of the items selected to the Sprint. Based on my experience this can also be an element of the regular **Backlog Refinement process.** There are multiple ways of estimation eg. Planning Poker (by using Fibonacci sequence), T-shirt sizes, Dog sizes etc. 

The main purpose of this activity is to have a **discussion about items** & to use the sum of estimates to calculate the **Velocity.** It is a great tool that can be used during the planning of the next Sprint.

When all the work is discussed, understood and planned, [Developers](/blog/scrum-roles-1-development-team) can **start their work.** If they discover that they didn’t select enough items for the Sprint Backlog or they selected too many, it can be re-negotiated with the  [Product Owner](/pl/blog/scrum-roles-2-product-owner).

## Summary

The most important takeaways from this post are: 

* Scrum Team [Developers](/blog/scrum-roles-1-development-team) , [Product Owner](/pl/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master)) should attend the Sprint Planning meeting. 
* Sprint Planning is time-boxed to **8 hours** per monthly Sprint.
* The [Product Owner](/pl/blog/scrum-roles-2-product-owner) should explain **“The Why”** of the Sprint - what is the value. Based on it, the whole Scrum Team crafts the  [Sprint Goal.](/blog/sprint-goal-why-do-we-need-it)
* PO and [Developers](/blog/scrum-roles-1-development-team) discuss **items selected for the Sprint,** but the final decision about it should be done by [Developers](/blog/scrum-roles-1-development-team).
* The inputs to the Sprint Planning can be: **projected capacity, velocity and their Definition of Done**.
* [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) & **Sprint Backlog** should be the outcome of the Sprint Planning.
* It is important for  [Developers](/blog/scrum-roles-1-development-team) to discuss **how they will be working d**uring the Sprint - all technical aspects: tools, boards, communication etc.
* [Developers ](/blog/scrum-roles-1-development-team)can **estimate** during the meeting (or during **Backlog Refinement)** how much effort is required to complete Product Backlog Items selected for the Sprint.

This article describes all aspects of the Sprint Planning meeting. It will help you to understand the purpose of this event, how it looks like & what you need to remember about. 

Scrum Events #2 Sprint Planning

\*This post has been updated as per [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html#).

## Introduction

Scrum framework consists of **5 events** (listed below) that are **time-boxed** and they help to **minimize** the need for other meetings. They also create **consistency** which improves efficiency of the work.

* Sprint 
* Sprint Planning
* Daily Scrum
* Sprint Review
* Sprint Retrospective

The next 5 posts will be describing each of the 5 Scrum events in detail.
[Scrum](/blog/first-steps-to-learn-scrum/) events help to organize the structure of each iteration. That’s how we can create a **safe** work environment and trigger **creativity** in the team.

![Scrum Framework](img/scrum_framework.webp "Scrum Framework")

## The Sprint - Definition & Length

Based on the [Scrum Guide](https://scrumguides.org/scrum-guide.html#):

> Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

The best way to imagine what is the Sprint in [Scrum](/blog/first-steps-to-learn-scrum/) is using the **sprint’s sport analogy.** As we all know, a sprint is a **short distance** run, typically focused on quickly reaching the goal.

That’s exactly how the Sprint looks like in [Scrum](/blog/first-steps-to-learn-scrum/). It is quite a short time period (**maximum one month**) focused on achieving the **Sprint Goal** crafted at the beginning during the **planning** session.

It is important to keep Sprints **short** to be able to **adjust** to the changing world and avoid the **risk** of **increased** complexity. It also helps to keep **focused** on the goal.

Imagine that you are running a short distance - you can see the finishing line and it **motivates** you to run faster. Long distance running requires much more **planning**. We don’t want to use all our energy at the beginning, so it needs to be accumulated till the end. It’s easy to make that mistake - run too fast when we start and be too tired at the end. Sometimes when we plan our run, we don’t consider important factors, which can **change** our result.

**Product development** works better when we work in **short periods of time.** It helps to avoid risk related to **changes** that we didn’t consider. That’s why the Sprint in Scrum is short enough to see the **horizon/Sprint Goal,** but long enough to **create releasable product increment.**

![sprint](img/sprint.webp "sprint")

## Iteration

[Scrum](/blog/first-steps-to-learn-scrum/) promotes an **iterative approach** which means that all activities are done in **cycles.** During the **Sprint** we discover what is working, what should be changed and we adjust it. The next Sprint starts **immediately** after the previous one and we can use the knowledge that we gained in the previous Sprint.

The main benefit of **short cycles** is the opportunity to **get early feedback** from stakeholders and **adapt** to the market.

## Frame

Scrum is a **framework** and I imagine the **Sprint** as a **frame** that consists of everything else. During the **Sprint**, Scrum Team is focused on the **current iteration** and **all actions** are referring to the **current Sprint:**

* Sprint Planning - time for planning the whole **Sprint**
* Sprint Goal - what we want to achieve during **the Sprint**
* Sprint Backlog - work items planned for **the Sprint**
* Daily Scrum - plan for each day of **the Sprint**
* Sprint Review - to discuss what was done during **the Sprint**
* Sprint Retrospective - inspection of what was good and what should be improved based on **the Sprint**.

As you can see all actions are focused on the current iteration - **the Sprint**.

Of course the Product Owner needs to have some high level vision of the **whole development** of the product and **other Sprints.** That’s why he or she creates the **Product Backlog,** that includes all work items related also to the **future change** of the product. They also craft the **Product Goal** to give everyone direction. 

It is important to remember that Product Backlog is **flexible** and can be adjusted, changed, but **Sprint Backlog** is more fixed. It can be clarified, changed but that needs to be agreed between the Product Owner and Developers.

Changes that could **negatively impact** the **Sprint Goal** or **quality** are not allowed during the Sprint.

## Cancelling the Sprint

In [Scrum](/blog/first-steps-to-learn-scrum/) it is allowed to **cancel the Sprint** if **Sprint Goal** is **out-of-date** due to the technology change or different market situation. I would say that it is a really **rare** situation, but it can happen and it can be done **only by the Product Owner** - the only person who has **authority to cancel the Sprint.**

From a technical perspective when Sprint is cancelled, **"Done" work items need to be reviewed**. If they are potentially **releasable**, they can be accepted by the Product Owner. The approach related to other incomplete items is similar like at the end of a normal Sprint. They go back to the Product Backlog and Developers will need to re-estimate them.

## Summary

To sum up:

* The **Sprint** is an **event** in the [Scrum](/blog/first-steps-to-learn-scrum/) framework that can take a **maximum one month.**
* Sprint helps the Developers to **focus** on the work that needs to be done and **achieve the Sprint Goal.** It is also the **frame** for all other events, actions and definitions in the Scrum.
* **Cancellation** of the Sprint is possible, but it is uncommon and it can be done **only by the Product Owner.**

I hope that this post helped you to understand the basic idea of the **Sprint**. I will continue describing all other Scrum events in my next posts.

This is the first post in the Scrum Events series that will help you to understand what the Sprint is and what is its role in Scrum.

5 posts tagged with #scrum events